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Foreword 

ISO (the International Organization for Standardization) and lEC (the International Elec- 
trotechnical Commission) form the specialized system for worldwide standardization. Na- 
tional bodies that are members of ISO or lEC participate in the development of Interna- 
tional Standards through technical committees established by the respective organization 
to deal with particular fields of technical activity. ISO and lEC technical committees col- 
laborate in fields of mutual interest. Other international organizations, governmental and 
non-govemmentat, in liaison with ISO and lEC, also take part in the work. 

In the field of information technology, ISO and lEC have established a joint technical com- 
mittee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical 
committee are circulated to national bodies for voting. Publication as an International 
Standard requires approval by at least 75% of the national bodies casting a vote. 

International Standard ISO/IEC 9798-3 was prepared by Joint Technical Committee 
ISO/IEC JTC 1, Information technology, Subcommittee SC27, IT Security techniques. 

This second edition cancels and repl2ices the first edition (ISO/IEC 9798-3:1993), which 
has been technically revised. Note, however, that implementations which comply with 
ISO/IEC 9798-3 (1st edition) will be compliant with ISO/IEC 9798-3 (2nd edition). 

ISO/IEC 9798 consists of the following parts, under the general title Information technology 
^ Security techniques — Entity authentication: 

- Part J: General 

- Part 2: Mechanisms using symmetric encipherment algorithms 

- Part 3: Mechanisms using digital signature techniques 

- Part 4- Mechanisms using a cryptographic check function 

- Part 5: Mechanisms using zero knowledge techniques 



Further parts may follow. 

Annex A of tlus part of ISO/IEC 9798 is for information only. 
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Information technology — Security techniques — 
Entity authentication — 
Part 3: 

Mechanisms using digital signature techniques 



1 Scope 



3 Definitions and notation 



This part of ISO/IEC 9798 specifies entity authentica- 
tion mechanisms using digital signatures based on asym- 
metric techniques. Two mechanisms are concerned with 
the authentication of a single entity (unilateral authenti- 
cation), while the remaining are mechanisms for mutual 
authentication of two entities. A digital signature is 
used to verify the identity of an entity. A trusted third 
party may be involved. 

The mechanisms specified in this part of ISO/IEC 9798 
use time variant parameters such as time stamps, se- 
quence numbers, or random numbers, to prevent valid 
authentication information from being accepted at a 
later time. 

If a time stamp or a sequence number is used, one pass 
is needed for unilateral authentication, while two passes 
are needed to achieve mutual authentication. If a chal- 
lenge and response method employing random numbers 
is used, two passes are needed for unilateral authen- 
tication, while three or four passes (depending on the 
mechanism employed) are required to achieve mutual 
authentication. 



2 Normative reference 

The following standard contains provisions which, 
through reference in this text, constitute provisions of 
this part of ISO/IEC 9798. At the time of publica- 
tion, the edition indicated was valid. All standards are 
subject to revision, and parties to agreements based on 
this part of ISO/IEC 9798 are encouraged to investi- 
gate the possibility of applying the most recent edition 
of the standard indicated below. Members of TEC and 
ISO maintain registers of currently valid International 
Standards. 

ISO/IEC 9798-1: 1997, Information technology — 5c- 
curity techniques — Entity authentication — Part 1: 
General. 



For the purposes of this part of ISO/IEC 9798 the defini- 
tions and notation described in ISO/IEC 9798-1 apply. 



4 Requirements 

In the authentication mechanisms specified in this part 
of ISO/IEC 9798 an entity to be authenticated corrob- 
orates its identity by demonstrating its knowledge of its 
private signature key. This is achieved by the entity us- 
ing its private signature key to sign specific data. The 
signature can be verified by anyone using the entity's 
public verification key. 

The authentication mechanisms have the following re- 
quirements: 

a) A verifier shall possess the valid public key of the 
claimant, i.e., of the entity that the claimant claims to 
be. 

b) A claimant shall have a private signature key known 
and used only by the claimant. 

If either of these is not satisfied then the authentication 
process may be compromised or it cannot be completed 
successfully. 

NOTES 

1 One way of obtaining a valid public key is by means 
of a certificate (see Annex C of ISO/IEC 9798-1). The 
generation, distribution, and revocation of certificates 
are outside the scope of this part of ISO/IEC 9798. 
There may exist a trusted third party for this pur- 
pose. Another way of obtaining a valid public key is 
by trusted courier. 

2 References to digital signature schemes are contained 
in Annex D of ISO/IEC 9798-1. 
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5 Mechanisms 

The specified entity authentication mechanisms make 
use of time variant parameters such as time stamps, se- 
quence numbers or random numbers (see Annex B of 
ISO/IEC 9798-1 and Note 1 below). 

Throughout this part of ISO/IEC 9798, tokens have the 
following form: 

Token = Xi||...||AM|5S^(ri|I.-.||yi). 

In this part of ISO/IEC 9798, the term "signed data" 
refers to "yi|| "|Pi" used as input to the signa- 
ture scheme and the term "unsigned data" refers to 
"Xill-.-IIX.". 

I If information contained in the signed data of the token 
I can be recovered from the signature, then it need not 
i be contained in the unsigned data of the token (see, for 
I example, ISO/IEC 9796). 

s 

I If information contained in the text field of the signed 
g data of the token cannot be recovered from the signa- 
I ture, then it shall be contained in the unsigned text field 
I of the token. 

I If information in the signed data of the token (e.g., a 

1 random number) is already known to the verifier, then 

2 it need not be contained in the unsigned data of the 
i token sent by the claimant. 

I All text fields specified in the following mechanisms are 
f available for use in applications outside the scope of this 
I part of ISO/IEC 9798 (they may be empty). Their re- 
I lationship and contents depend upon the specific appli- 
I cation. See Annex A for information on the use of text 

I fields. 

1 
t 

I NOTES 

= 1 The signing by one entity of a data block which has 

s been manipulated by a second entity for some ulterior 

I motive can be prevented by the first entity including its 

I own random number in the data block which it signs. 

1 In this case, it is the unpredictability which prevents 

I the signing of pre-defined data. 

^ 2 As the distribution of certificates is outside the scope 

I of this part of ISO/IEC 9798, the sending of certificates 

I is optional in all mechanisms. 

1 

1 5.1 Unilateral authentication 

I Unilateral authentication means that only one of the 
I two entities is authenticated by use of the mechanism. 

1 5.1.1 One pass authentication 

§ 

I In this authentication mechanism the claimant A ini- 
I tiates the process and is authenticated by the verifier 



B. Uniqueness / timeliness is controlled by generating 
and checking a time stamp or a sequence number (see 
Annex B of ISO/IEC 9798-1). 

The authentication mechanism is illustrated in figure 1. 



A 


(1) Cert>l||Token>lB 


B 





(2) 



Figure 1 



The form of the token (Tokenj4S), sent by the claimant 
A to the verifier B is: 

TokcnAB = ||B||Text2||s5x ( ||B||Textl). 

where the claimant A uses either a sequence number 
Na or a time stamp Ta as the time variant parameter. 
The choice depends on the technical capabilities of the 
claimant and the verifier as well as on the environment 

NOTES 

1 The inclusion of the identifier B in the signed data of 
TokenAB is necessary to prevent the token from being 
accepted by anyone other than the intended verifier. 

2 In general, Text2 is not authenticated by this pro- 
cess. 

3 One application of this mechanism could be key dis- 
tribution (see Annex A of ISO/IEC 9798-1). 

(1) i4 sends Tokeni4B and, optionally, its certificate to 
B. 

(2) On receipt of the message containing Token>lB, B 
performs the following steps: 

(i) It ensures that it is in possession of a valid 
public key of .i4 either by verifying the certifi- 
cate of A or by some other means. 

(ii) It verifies TokenAB by verifying the signature 
of A contained in the token, by checking the 
time stamp or the sequence number, and by 
checking that the value of the identifier field 
(B) in the signed data of TokenAB is equal to 
entity B's distinguishing identifier. 

5.1.2 Two pass authentication 

In this authentication mechanism the claimant A is 
authenticated by the verifier B who initiates the pro- 
cess. Uniqueness / timeliness is controlled by generat- 
ing and checking a random number Rb (see Annex B of 
ISO/IEC 9798-1). 



I 



© ISO/IEC 



ISO/IEC 9798-3:1 998(E) 



The authentication mechanism is illustrated in figure 2. 





(l)flflllTextl 








B 


A 


(2) CerU||TokenAB 



(3) 



Figure 2 



The form of the token (Tokeni4B), sent by the claimant 
A to the verifier B is: 

. TokcnAB = HA||/l5||B||Text3||5S^ (/lAllHB||B||Tcxt2). 

The inclusion of identifier B in Tokenj4B is optional. It 
depends on the environment in which this authentica- 
tion mechanism is used. 

NOTES 

1 The inclusion of the optional identifier B in the signed 
data of Token/15 can prevent the token from being ac- 
cepted by anyone other than the intended verifier (e.g., 
in a person-in-the-middle attack). 

2 The inclusion of the random number Ra in the signed 
part of Tokeni4B prevents B from obtaining the signa- 
ture of A on data chosen by B prior to the start of the 
authentication mechanism. This measure may be re- 
quired, for example, when the same key is used by A 
for purposes other than entity authentication. 

(1) B sends a random number Kb and, optionally, a 
text field Textl to A, 

(2) A sends Tokeni45 and, optionally, its certificate to 
B. 

(3) On receipt of the message containing Tokeni4B, B 
performs the following steps: 

(i) It ensures that it is in possession of a valid 
public key of A either by verifying the certifi- 
cate of A or by some other means. 

(ii) It verifies Tokeni45 by checking the signature 
of A contained in the token, by checking that 
the random number Hb, sent to A in step (1), 
agrees with the random number contained in 
the signed data of TokenAB, and by checking 
that the value of the identifier field [B] in the 
signed data of Tokeni4B, if present, is equal 
to B's distinguishing identifier. 

5.2 Mutual authentication 

Mutual authentication means that the two communicat- 
ing entities are authenticated to each other. 

The two mechanisms described in 5.1.1 and 5.1.2 are 
extended in 5.2.1 and 5-2.2, respectively, to achieve mu- 
tual authentication. This is done by transmitting one 
further message resulting in two additional steps. 



The mechanism specified in 5.2.3 uses four messages 
which, however, need not all be sent consecutively. In 
this way the authentication process may be speeded up. 

5.2.1 Two pass authentication 

In this authentication mechanism uniqueness / time- 
liness is controlled by generating and checking time 
stamps or sequence numbers (see Annex B of 
ISO/IEC 9798-1). 

The authentication mechanism is illustrated in figure 3. 







(I) CertA||TokenAB 




(4) 


A 




B 


'(3) Ccrt5|lTokcnB>l 





(2) 



Figure 3 

The form of the token (Tokeni4B), sent by A to B, is 
identical to that specified in 5.1.1. 

TokenAB = ||B||Text2||5S^ ( ||B||Textl). 
The form of the token (TokenBi4), sent by B to ^4, is: 

TokcnB.4= J« ||A||Text4l|5Sfl ( ||Al|Tcxt3). 

The choice of using either time stamps or sequence num- 
bers in this mechanism depends on the technical capa- 
bilities of the claimant and the verifier as well as on the 
environment. 

NOTE 1 — The inclusion of identifiers A and B in the 
signed data of TokenB^l and Tokeni4B, respectively, is 
necessarj' to prevent the tokens from being accepted by 
anyone other than the intended verifier. 

Steps (1) and (2) are identical to those specified in 5.1.1, 
one pass authentication. 

(3) B sends TokenBi4 and, optionally, its certificate to 
.4. 

(4) The message in step (3) is handled in a manner 
analogous to step (2) of 5.1.1. 

NOTE 2 — The two messages of this mechanism are 
not bound together in any way, other than implicitly 
by timeliness; the mechanism involves independent use 
of mechanism 5.1.1 twice. Further binding together of 
these messages can be achieved by making appropriate 
use of the text fields. 
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5.2.2 Three pass authentication 

In this authentication mechanism uniqueness / timeli- 
ness is controlled by generating and checking random 
numbers (see Annex B of ISO/IEC 9798-1). 

The authentication mechanism is illustrated in figure 4. 



(1) /?B||Tcxtl 



(5) 
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(2) Cert/i||Token>lS 


B 






(4) CertB||TokenB>l 












Figure 4 





(3) 



The tokens are of the following form: 

I ToktnAB = H^||/?B||B||Text3||5S^ (H^||flB||B||Tcxt2), 

I TokenBA = /?fl||/?AlMI|Tcxt5||5Sfl (flBl|HA||A|lText4). 

|The inclusion of the parameter B in TokenAB and the 
|inclusion of the parameter A in TokenBi4 are optional. 
|They depend on the environment in which this authen- 
Itication mechanism is used. 

1 NOTE — The inclusion of the random number Ra in 

f the signed part of Tokeni4B prevents B from obtaining 

& the signature of A on data chosen by B prior to the start 

I of the authentication mechanism. This measure may be 

5 required, for example, when the same key is used by A 

I for purposes other than entity authentication. However, 

I the inclusion of Rb in TokenBi4, whilst necessary for 

t security reasons which dictate that A should check that 

I it is the same as the value sent in the first message, may 

I not offer the same protection to B, since Rb is known 

I to i4 before Ra is chosen. If this type of protection 

I is required, B can insert an additional random number 

I Rb in the text fields Text4 and Texts of TokenB/l. 

1(1) B sends a random number Rb and, optionally, a 

I text field Textl to A. 

s 

I (2) A sends Tokeni4B and, optionally, its certificate to 

I ^' 

iS 

••(3) On receipt of the message containing TokenylB, B 

f performs the following steps: 

! (i) It ensures that it is in possession of a valid 

I public key of A either by verifying the certifi- 

i cate of A or by some other means. 
I 

« (ii) It verifies TokenAB by checking the signature 

I of i4 contained in the token, by checking that 

§ the random number Rsy sent to A in step (1), 

I agrees with the random number contained in 

I the signed data of TokenAB, and by checking 

i that the value of the identifier field (B) in the 

5 signed data of TokenAB, if present, is equal 

J to B's distinguishing identifier. 



(4) B sends TokenBA and, optionally, its certificate to 
A. 

(5) On receipt of the message containing TokenBA, A 
analogously performs steps (i) and (ii) listed under 
(3). In addition, A checks that the random number 
Rb contained in the signed data of TokenBA is 
equal to the random number Rb received in step 
(!)• 

5.2.3 Two pass parallel authentication 

In this mechanism authentication is carried out in par- 
allel. Uniqueness / timeliness is controlled by gener- 
ating and checking random numbers (see Annex B of 
ISO/IEC 9798-1). 

The authentication mechanism is illustrated in figure 5. 







(1) CeVtv4||fl,i||Textl 
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Figure 5 

The tokens are similar to those of clause 5.1.2: 

Tokcn.4B = H^||;?B||B||Text4||55^ (/?^||HfiIjB||Tc.xt3), 
TokcnB.4 = /lB||/?,ip||Tcxt6||5Sfl {HsIIH/tlMIITextS). 

The inclusion of the parameter B in TokenAB and the 
inclusion of the parameter A in Token Bj4 are optional. 
They depend on the environment in which this authen- 
tication mechanism is used. 

NOTE 1 — The random number Ra is present in 
TokenAB to prevent B from obtaining the signature 
of A on data chosen by B prior to the start of the au- 
thentication mechanism. This prevention may be re- 
quired, for example, when the same key is used by A 
for other purposes in addition to entity authentication. 
For similar reasons the random number Bs is present in 
TokenB.4. Depending on the relative time of receipt of 
the messages sent in steps (1) and (T), one of the parties 
may know the random number of the other party when 
choosing its random number. If this is luidesirable, both 
parties can insert an additional random number R'^ and 
Rb in the text fields Texts and Text4 of TokenAB, and 
Texts and Text 6 of TokenBA, respectively. 

(1) A sends Ra and, optionally, its certificate and a 
text field Textl to B. 

(r) B sends Rb and, optionally, its certificate and a 
text field Text2 to A. 
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(2) A and B ensure that they are in possession of a valid 
public key of the other entity either by verifying the 
respective certificate or by some other means. 

(3) A sends TokenAB to B, 
(3') B sends TokenB^ to A, 

(4) A and B perform the following steps: 

Each of them verifies the received token by checking 
the signature contained in the token and by check- 
ing that the random number, which it previously 
sent to the other entity, agrees with the random 
number contained in the signed data of the token 
received. 

NOTE 2 — An alternative to mecheuiism 5.2.3 is to run 
mechanism 5.1.2 both ways. The inclusion of the cer- 
tificates in the first messages of mechanism 5.2.3 allows 
for earlier certificate verification which may speed up 
the authentication process. 
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Annex A 
(informative) 

Use of text fields 



The tokens specified in clause 5 of this part of 
[SO/IEC 9798 contain text fields. The actual use of 
and the relationships between the various text fields in 
a given pass depend on the application. Some examples 
ire given below; see also Annex A of ISO/IEC 9798-1. 

[f a signature scheme without message recovery is used 
and if the signed text field is not empty, then the verifier 
lieeds to be in possession of the text prior to verifying the 
fsignature. In this Annex "signed text fields" refers to 
Jtext fields in the signed data and "unsigned text fields" 
|refers to text fields in the unsigned data. 

iFor example, if a digital signature scheme without mes- 
sage recovery is used, any information requiring data 
prigin authentication should be placed in the signed text 
field and (as part of) the unsigned text field in the token. 

the tokens do not contain (sufficient) redundancy, the 
^igned text fields may be used to provide additional re- 
dundancy. 



Signed text fields may be used to indicate that the token 
is only valid for the purpose of entity authentication. 
Should there be a concern that one entity might choose 
a "degenerate" value with malicious intent for the other 
entity to sign, the other entity may introduce a random 
number in the text field. 

Should an algorithm be used where it may be possi- 
ble to launch attacks based on the fact that a particular 
claimant is using the same key for all verifiers with which 
the claimant communicates, and if such attacks are con- 
sidered to be a threat, the identity of the intended ver- 
ifier should be included in the signed text field and, if 
necessary, in the unsigned text field. 

Unsigned text fields can also be used to provide informa- 
tion to a verifier indicating the (unauthenticated) iden- 
tity which a claimant is claiming. If means other than 
certificates are used for distributing public keys, such 
information may be required to allow a verifier to deter- 
mine which public key is to be used to authenticate a 
claimant. 



